Field of the Invention
The present invention relates to the use of UEFI firmware management and more particularly to database management in a UEFI secure boot driver.
Description of the Related Art
The Unified Extensible Firmware Interface (UEFI) is a computing specification that defines a software interface between an operating system and platform firmware. UEFI replaces the venerable Basic Input/Output System (BIOS) firmware interface, originally present in all “IBM-compatible” personal computers. Unlike the legacy BIOS technology, in UEFI a boot sector is not required. Rather, UEFI defines the boot manager as part of the UEFI compliant firmware. As such, when a computer initially powers on, the boot manager checks the boot configuration, and according to the boot configuration, the boot manager loads and executes the specified operating system loader, or in the alternative, a specified operating system kernel.
The UEFI specification adds a protocol known as “UEFI secure boot”. UEFI secure boot secures the boot process by preventing the loading of drivers or operating system loaders that are not signed with an acceptable digital signature. When UEFI secure boot is enabled, secure boot initially is placed in “setup” mode, which allows a public key known as the platform key (PK) to be written to the firmware. Once the key is written, secure boot enters a user mode, in which only drivers and loaders signed with the platform key can be loaded by the firmware. Additional “key exchange keys” (KEK) may be added to a database stored in memory to allow other certificates to be used, but all KEKs must still have a connection to the private portion of the PK. UEFI Secure boot can also be placed in a custom mode, in which additional public keys can be added to the system that do not match the private key. Specifically, in custom Mode a default set of keys and databases are presented as in an ordinary user mode, but in custom mode, the end user is permitted to add or remove any of the keys and databases. In any case, as can be seen, secure boot prevents unauthorized operating systems and software from loading during the startup process.
Of note each manufacturer of an auxiliary component of a computer provide in advance to the computer manufacturer the requisite driver or drivers necessary for the auxiliary component to perform in connection with the computer in which the auxiliary component is to be installed. In this way, the computer manufacturer can include a signed form of the driver in the UEFI firmware. However, oftentimes, new auxiliary components are produced after the deployment of a computer. Thus, the UEFI firmware must permit the ad hoc addition of new signed drivers to the UEFI firmware. As well, to the extent that older drivers no longer remain valid or are replaced with new versions of the same driver, the UEFI firmware must permit the ad hoc removal of the older signed drivers from the UEFI firmware.
To support the ad hoc addition and removal of signed drivers to the UEFI firmware, the UEFI firmware enjoys access to each of a signature database, a revoked signature database, and a KEK database. These databases are stored on the flash at manufacturing time. The signature database and the revoked signatures database list the signers or image hashes of UEFI applications, operating system loaders, and UEFI drivers that can be loaded on the server, and the revoked images for items that are no longer trusted and may not be loaded. The KEK database is a separate database of signing keys that can be used to update the signature database and revoked signatures database.
Once the signature and revoked signatures database and KEK database have been added to the UEFI firmware, subsequent to final firmware validation and testing, the computer manufacturer locks the firmware from editing, excepting for updates that are signed with the correct key or updates by a physically present user utilizing firmware menus, and generating a resulting PK. The PK thereafter can be used to sign updates to the KEK or to disable secure boot. In general, there is a precedence order from most significant to least significant of PK, KEK, signatures database and revoked signatures database. The rules of precedence first require that in order to update a KEK a signature with the correct PK must be provided. Also, in order to update a signatures database or a revoked signatures database, a signature with the correct PK or KEK must be provided.
Of note, if a signing certificate is enrolled in a signatures database, then all images signed by that certificate are run, unless that certificate or individual signatures are found in the revoked signatures database. Even yet further, if a certificate of an image is not found in the signatures database, but a signature for the certificate is found, then the image is run, unless a corresponding certificate or signature is found in the revoked signatures database. Likewise, if a certificate or signature of an image is found in the revoked signatures database, then the image is not run, even if certificate or signature is found in the signatures database. Finally, if an image is properly signed, but neither its certificate nor signature is found in signatures database, then the image is not run, and also, unsigned images are not run. Give the complexity of the rules of precedence, the ad hoc addition or removal of a key can have wide reaching consequences not readily ascertainable by the end user.